Langkah 1: 


Menemukan & Menganalisis 
Fakta 


41 PENDAHULUAN 


Bab ini menjelaskan langkah pertama dari perancangan basis data. Lang- 
kah ini meliputi pengumpulan dan penganalisisan kebutuhan pemakai 


yang dilakukan dengan tahapan sebagai berikut. 


1. Mengidentifikasi bagian organisasi yang akan didukung oleh 
aplikasi basis data. 


2. Mengidentifikasi pemakai utama basis data. 
3. Melakukan pencarian informasi atau penemuan fakta. 
4. Merangkum hasil penemuan fakta. 


Output langkah ini adalah sebuah dokumen yang berisikan penjelasan 
rinci tentang kebutuhan data, kebutuhan transaksi, dan kebutuhan sistem 
dari pemakai basis data. Dokumen ini disebut dengan Dokumen 
Spesifikasi Kebutuhan Pemakai (Users' Requirement Specification 


Document). 
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4.2 IDENTIFIKASI BAGIAN ORGANISASI 


Tujuan langkah ini adalah mengidentifikasi bagian organisasi yang akan 
didukung oleh aplikasi basis data. Misalnya, jika basis data yang dibuat 
akan menyimpan data dokter, pasien, obat-obatan, dan tindakan medis, 
maka bagian rumah sakit yang akan didukung adalah Bidang Medik, 
Bidang Keperawatan, Bidang Rekam Medik, dan Unit Farmasi. 


Pengidentifikasian dapat dilakukan dengan melihat struktur organisasi, 


dokumentasi organisasi, dan/atau menanyakan langsung kepada pemakai. 


4.3 IDENTIFIKASI PEMAKAI UTAMA 


Tujuan langkah ini untuk menentukan pemakai pada bagian organisasi 
yang telah diidentifikasi pada langkah sebelumnya. Untuk setiap bagian 
organisasi, tentukan pemakai atau personil yang memiliki kepentingan 
terhadap aplikasi basis data yang akan dibuat. Personil tersebut dapat 


berupa orang-orang yang memiliki jabatan tertentu atau para staf. 


Contoh pemakai pada basis data universitas adalah dosen, mahasiswa, 
ketua jurusan/program studi, dan staf bagian administrasi akademik & 
kemahasiswaan (BAAK), sedangkan contoh pemakai pada basis data 


rumah sakit adalah dokter, perawat, apoteker, dan kasir. 


4.4 PENEMUAN FAKTA 


Tujuan langkah ini untuk melakukan penemuan fakta di lapangan terkait 
dengan kebutuhan pemakai terhadap data, transaksi, dan sistem pada saat 


pemakai menggunakan aplikasi basis data. 
Metode penemuan fakta yang dapat digunakan adalah sebagai berikut: 


e Pengajian dokumen terkait. Metode ini akan membantu dalam 
menemukan alasan kenapa basis data perlu dibangun, mema- 


hami bagian organisasi terkait dengan pembangunan basis data, 
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dan memahami keadaan sistem yang sedang berjalan saat ini. 
Dokumen yang dikaji dapat berupa rencana strategis organisasi, 


bagan organisasi, dan dokumentasi aplikasi yang digunakan. 


Interview. Metode ini meliputi teknik penemuan fakta yang 
sering digunakan dalam pengumpulan informasi dengan cara 
bertanya langsung kepada pemakai. Teknik ini digunakan untuk 
membuktikan dan mengklarifikasi fakta, mengidentifikasi kebu- 
tuhan pemakai terhadap aplikasi yang akan dibuat, dan me- 


ngumpulkan ide dari pemakai. 


Observasi kegiatan di lapangan. Teknik ini dilakukan untuk 
memahami prosedur atau pekerjaan pemakai yang akan didu- 


kung oleh aplikasi basis data yang akan dibuat. 


Penyebaran kuesioner. Teknik ini dilakukan untuk mengum- 


pulkan informasi dari para pemakai yang berjumlah besar. 


Dengan menggunakan satu atau lebih teknik penemuan fakta di atas, dan 


menjadikan para (calon) pemakai dan sistem yang sudah ada sebagai 


sumber informasi, galilah informasi berikut: 


1. 


2; 


Sasaran dari misi pembangunan basis data (mission objective). 


Kebutuhan data yang akan disimpan pada basis data (data 


requirements). 


Kebutuhan transaksi terhadap data yang akan disimpan pada 


basis data (transaction requirements). 


Kebutuhan sistem basis data yang akan dibuat (system 


requirements). 


Perlu diperhatikan bahwa pada langkah ini tercakup pengidentifikasian 


view pemakai. View pemakai mendefinisikan hal-hal yang dibutuhkan 


oleh sistem basis data dari sudut pandang jabatan/tugas pemakai tertentu 
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(misalnya dokter, apoteker, dan pasien) atau dari sudut pandang pema- 
kaian aplikasi (misalnya aplikasi riwayat penyakit pasien dan aplikasi 
pengelolaan obat-obatan). Kebutuhan pemakai ini dapat berbeda satu 
sama lain atau dapat juga terjadi overlap. Karena bisa terdapat lebih dari 
satu jenis jabatan dan jenis pemakaian aplikasi, maka sistem basis data 


dapat memiliki lebih dari satu view pemakai. 


LAI Penggalian Sasaran Misi 


Tanyakanlah misi kepada pemilik proyek pembangunan basis data dan 
galilah sasaran dari misi tersebut. Untuk penggalian sasaran misi, lakukan 
interview kepada setiap pemakai terpilih menggunakan beberapa contoh 


pertanyaan terbuka berikut: 
e Deskripsi pekerjaan Anda? 
e Pekerjaan apa saja yang Anda lakukan pada setiap hari? 
e Data apa saja yang dilibatkan pada pekerjaan Anda tersebut? 
e Jenis laporan apa saja yang Anda gunakan? 
e Apa saja yang selalu ingin Anda monitor? 


e Pelayanan apa saja yang diberikan oleh perusahaan atau organi- 


sasi Anda kepada pelanggan/tamu? 


E Contoh 4.1: Wawancara dan Penggalian Sasaran Misi dengan 
Seorang Dokter di Rumah Sakit 


e Deskripsi pekerjaan Anda? 


"Pekerjaan saya adalah memeriksa dan mendiagnosa penyakit 
pasien, baik pasien rawat jalan maupun pasien rawat inap. 


Pemeriksaan harus dilakukan secara cepat dan tepat." 


e Pekerjaan apa saja yang Anda lakukan pada setiap hari? 
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"Dari jam 06.00 s.d. 09.00 saya memeriksa pasien yang sedang 
dirawat. Dari hasil pemeriksaan, saya akan memutuskan apakah 
pasien tersebut tidak perlu dirawat lagi, perlu pengurangan/ 
penambahan obat, dan/atau perlu dilakukan tindakan medis 
lainnya. Dari jam 09.00 s.d. jam 17.00 saya melayani pasien rawat 
jalan. Saya memberikan resep obat, melakukan rekam medis, 
dan/atau memberikan nasihat kepada pasien untuk tindakan 


perawatan dan pencegahan." 
e Data apa saja yang dilibatkan pada pekerjaan Anda tersebut? 


"Data riwayat penyakit pasien, data tindakan medis terhadap 
pasien, data obat yang telah diberikan kepada pasien, dan data 


jenis obat yang tersedia di rumah sakit." 
e Jenis laporan apa saja yang Anda gunakan? 


"Jumlah pasien yang telah dirawat beserta tindakan medis yang 
telah dilakukan." 


e Apa saja yang selalu ingin Anda monitor? 


"Tindakan medis pasien yang sedang dirawat di rumah sakit yang 


dalam penanganan saya." 


e Pelayanan apa saja yang diberikan oleh perusahan/organisasi 


Anda kepada pelanggan/tamu? 


"Melaksanakan pelayanan medis (khusus, penunjang, dan 
tambahan), melaksanakan pelayanan rujukan kesehatan, dan 


melaksanakan pelayanan rawat inap dan rawat jalan." 


Dari potongan hasil wawancara di atas, dapat disimpulkan bahwa sasaran 
misi pembangunan basis data pada rumah sakit tersebut, di antaranya 


sebagai berikut: 


e Mengelola data pasien 
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e Mengelola data obat 

e Mengelola data tindakan medis 

e Melakukan pencarian data pasien 

e Melakukan pencarian data obat 

e Melakukan pencarian data tindakan medis 

e Memonitor tindakan medis yang telah dilakukan kepada pasien 
e Melaporkan jumlah pasien yang telah ditangani 

e Melaporkan tindakan medis yang telah diberikan 


Perhatikan bahwa pengelolaan data meliputi aktivitas rekam, ubah, dan 
hapus data. Contoh di atas adalah sasaran misi yang didapat dari hasil 
wawancara pada satu orang dokter. Idealnya penggalian sasaran misi 
sebaiknya dilakukan berdasarkan hasil wawancara dari berbagai jenis 
kelompok pemakai, dan menyimpulkan hasil wawancara tersebut menjadi 


sasaran misi dalam format seperti contoh di atas. W 


LA. Penggalian Kebutuhan Data 


Temukan data yang menjadi perhatian utama pemakai dari sasaran misi 
pembangunan basis data yang telah dibuat pada langkah sebelumnya. 
Untuk setiap data (d), ajukan beberapa pertanyaan terbuka berikut untuk 
meng-gali lebih jauh atribut data yang akan disimpan pada basis data. 


e Jenis data/informasi apa saja yang Anda ingin ketahui tentang d? 
e Apa saja yang Anda lakukan terhadap data/informasi pada d? 
E Contoh 4.2: Wawancara dan Penggalian Kebutuhan Data 


Dari sasaran misi pada contoh di atas, maka data yang menjadi fokus 


utama adalah pasien, obat, dan tindakan medis. Untuk masing-masing 
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data, tanyakan lebih lanjut kepada pemakai (pada contoh ini dokter) 
tentang jenis informasi dan perlakuan terhadap data. Di bawah ini contoh 


hasil wawancara untuk data pasien: 


e Jenis data/informasi apa saja yang Anda ingin ketahui tentang 


pasien? 


"Nama, umur, berat badan, tinggi badan, tekanan darah, denyut 


nadi, pekerjaan, dan riwayat penyakit pasien." 


e Apa saja yang Anda lakukan terhadap data/informasi pada 


pasien? 


"Saya perlu untuk merekam data umur, berat badan, tinggi 
badan, tekanan darah, denyut nadi, dan hasil diagnosa penyakit 
pasien. Saya juga perlu menghapus atau menandai pasien yang 


telah meninggal." W 


LAI Penggalian Kebutuhan Transaksi 


Kebutuhan transaksi didefinisikan berdasarkan hasil wawancara pada dua 
langkah terdahulu. Kebutuhan transaksi dikelompokkan atas tiga jenis, 
yaitu transaksi perekaman data, transaksi pengubahan/penghapusan data, 


dan transaksi pengambilan data. 
E Contoh 4.3: Penggalian Kebutuhan Transaksi 


Berikut contoh kebutuhan transaksi yang diambil dari contoh sebe- 


lumnya. 

Transaksi Perekaman Data: 
e  Rekam/entri data detail pasien 
e  Rekam/entri data detail obat 


e  Rekam/entri data detail tindakan medis 
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Transaksi Pengubahan/Penghapusan Data: 
e  Ubah/hapus data detail pasien 
e  Ubah/hapus data detail obat 
e  Ubah/hapus data detail tindakan medis 
Transaksi Pengambilan Data: 
e Tampilkan data detail pasien tertentu 
e Tampilkan data detail pasien yang dirawat oleh dokter tertentu 


e Tampilkan data detail tindakan medis pasien tertentu yang 


dirawat oleh dokter tertentu 
e Tampilkan data detail obat untuk penyakit tertentu 
e Tampilkan jumlah pasien yang telah dirawat oleh dokter tertentu 
m 
444 Penggalian Kebutuhan Sistem 


Penggalian kebutuhan sistem bertujuan untuk menggali informasi umum 
yang dibutuhkan oleh sistem serta spesifikasinya. Pertanyaan ini dapat 
mengacu pada kebutuhan transaksi yang telah didapat pada langkah 


sebelumnya. 


Contoh dari beberapa pertanyaan yang dapat diajukan untuk menggali 


kebutuhan sistem adalah sebagai berikut: 
e Transaksi apa yang sering dijalankan pada basis data? 


e Transaksi apa yang kritis terhadap beroperasinya perusahaan/ 


organisasi? 


e Kapan transaksi kritis tersebut dijalankan? 
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Kapan waktu beban kerja rendah, sedang, dan tinggi dari 


transaksi kritis tersebut berlangsung? 
Jenis keamanan apa yang diinginkan pada sistem basis data? 


Apakah ada data penting yang hanya boleh diakses oleh orang- 


orang tertentu saja? 


Data histori apa saja yang ingin disimpan? 


Penggalian kebutuhan sistem juga meliputi penggalian spesifikasi sistem, 


yang di antaranya meliputi: ukuran awal basis data, laju pertumbuhan 


ukuran basis data, jenis dan rata-rata jumlah pencarian tuple, dan 


performa sistem yang diharapkan. 


HI Contoh 4.4: Hasil Penggalian Kebutuhan Sistem 


Berikut contoh kebutuhan sistem terhadap transaksi yang diambil dari 


contoh sebelumnya: 


Transaksi apa yang sering dijalankan pada basis data? 


"Menampilkan info detail pasien tertentu dan info detail obat 


untuk penyakit tertentu." 


Transaksi apa yang kritis terhadap beroperasinya perusahaan/ 


organisasi? 

"Menampilkan info tindakan medis oleh dokter tertentu." 
Kapan transaksi kritis tersebut dijalankan? 

"Setiap hari." 


Kapan waktu beban kerja rendah, sedang, dan tinggi dari 


transaksi kritis tersebut berlangsung? 


"Waktu yang tersibuk adalah waktu pemeriksaan pasien rawat 


inap, yaitu dari jam 06.00 s.d. 08.00. Sedangkan untuk waktu 
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normal dan rendah, masing-masing adalah waktu pemeriksaan 
pasien rawat jalan (09.00 s.d. 17.00) dan waktu setelah praktik 
dokter (17.00 s.d. 08.00)." 


Berikut contoh spesifikasi sistem yang dibutuhkan: 
e Ukuran awal basis data 
o Ada sekitar 1000 orang pasien yang terdaftar. 


o Ada sekitar 500 jenis obat-obatan yang digunakan di rumah 
sakit. 


o Ada sekitar 3000 tindakan medis yang telah dilakukan. 
e Laju pertumbuhan ukuran basis data 


o Rata-rata 5 pasien baru yang mendaftar setiap hari atau 
150 pasien baru per bulan. Pasien yang meninggal akan di- 
hapus dari basis data. Terdapat rata-rata 10 kali pengha- 


pusan pasien dalam sebulan. 


o Rata-rata 10 tindakan medis yang dilakukan pada setiap hari 


atau 300 tindakan medis per bulan. 


o Rata-rata 5 jenis obat baru yang didaftarkan pada setiap 
bulan. Obat yang tidak digunakan lagi akan dihapus dari 
basis data. Terdapat rata-rata 2 kali penghapusan obat lama 


pada setiap bulannya. 
e Jenis dan rata-rata jumlah pencarian tuple 


o Pencarian data detail pasien tertentu: rata-rata 150 kali per 


hari. 


o Pencarian data detail pasien yang dirawat dokter tertentu: 


rata-rata 100 kali per hari. 
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o Pencarian data detail tindakan medis pasien tertentu yang 


dirawat oleh dokter tertentu: rata-rata 25 kali per hari. 


o Tampilkan data detail obat penyakit tertentu: rata-rata 
200 kali per hari. 


o Tampilkan jumlah pasien yang telah dirawat oleh dokter 


tertentu: rata-rata 50 kali per bulan. 


e Performa sistem yang diharapkan 


o Pada jam operasional rumah sakit (06.00 s.d. 17.00) yang 


bukan jam tersibuk: 


Waktu respons sistem yang diharapkan pada saat pen- 


carian satu tuple adalah di bawah 2 detik. 


Waktu respons sistem yang diharapkan pada saat pen- 


carian beberapa tuple adalah di bawah 5 detik. 


Waktu respons sistem yang diharapkan pada setiap 
update atau penyimpanan data adalah di bawah 2 detik. 


o Pada jam operasional rumah sakit (06.00 s.d. 17.00) yang 


merupakan jam tersibuk: 


Waktu respons sistem yang diharapkan pada saat pen- 


carian satu tuple adalah di bawah 5 detik. 


Waktu respons sistem yang diharapkan pada saat pen- 


carian beberapa tuple adalah di bawah 10 detik. 


Waktu respons sistem yang diharapkan pada setiap 
update atau penyimpanan data adalah di bawah 5 detik. 
a 
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4.5 


RANGKUM HASIL PENEMUAN FAKTA 


Dari langkah sebelumnya, didapatkan satu atau lebih view pemakai yang 


menjelaskan tentang sasaran misi, kebutuhan data, kebutuhan transaksi, 


dan kebutuhan sistem. Terdapat tiga pendekatan untuk mengelola view 


pemakai yang jamak ini: 
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Pendekatan Terpusat (Centralized Approach) yang mengga- 
bungkan semua view pemakai menjadi satu view pemakai besar, 
dan kemudian membangun data model (entity relationship 


diagram) terhadap view pemakai besar tersebut. 


Pendekatan Pengintegrasian View (View Integration Approach) 
yang membangun data model lokal untuk masing-masing view 
pemakai, dan kemudian menggabungkan data-data model lokal 
tersebut menjadi satu data model global setelah melakukan nor- 


malisasi tabel (yaitu setelah melakukan langkah ke-4). 


Pendekatan Gabungan (Hybrid Approach) dengan cara sebagai 
berikut: 


1. Mengelompokkan view-view pemakai atas beberapa kelom- 


pok, 


2. Untuk setiap kelompok, gabungkan semua view pemakai 
pada kelompok tersebut menjadi satu view pemakai kelom- 
pok, 

3. Membangun data model untuk masing-masing view pema- 


kai kelompok, dan 


4. Menggabungkan data model view pemakai kelompok men- 
jadi satu data model global setelah melakukan normalisasi 
tabel. 


Pendekatan yang digunakan pada buku ini adalah pendekatan terpusat. 
Oleh karena itu, pada langkah ini rangkumlah hasil penemuan menjadi 
satu view pemakai global yang menghasilkan sebuah dokumen spesifikasi 


kebutuhan pemakai. 


Selain menuliskan visi (tujuan utama) dan misi (kegiatan tertentu untuk 
mencapai visi) pembangunan basis data, rangkuman juga menuliskan tiga 
sudut pandang, yaitu: kebutuhan data, kebutuhan transaksi, dan kebu- 
tuhan sistem. Contoh dari dokumen spesifikasi kebutuhan pemakai dapat 
dilihat pada Bab 11 Studi Kasus. 
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4.6 RINGKASAN MINDMAP 


bagian yg akan menggunakan basis data? 


1. Identifikasi bagian organisasi 
metode: 


lihat struktur organisasi 


lihat dokumentasi organisasi 


2. Identifikasi pemakai utama 


Langkah ke-1: Persiapan 


view pemakai 


3. Penemuan fakta 


metode: 


tanya pemakai 


siapa calon pemakai basis data? 
pejabat tertentu 


staf tertentu 
sasaran misi 

O 
kebutuhan data 2 


kebutuhan transaksi 


kebutuhan sistem 5 


kaji dokumen terkait 


interview pemakai 
observasi kegiatan 


penyebaran kuesioner 


dokumen spesifikasi 


4. Rangkum hasil penemuan 


metode kelola view 


kebutuhan pemakai 


terpusat 


pengintegrasian view 
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gabungan 


5.1 


2 


Langkah 2; 
Membuat ERD 


PENDAHULUAN 


Bab ini menjelaskan pembuatan Diagram Hubungan Entitas atau yang 


dikenal dengan sebutan Entity Relationship Diagram (ERD). Pembuatan 


ERD dilakukan berdasarkan dokumen spesifikasi kebutuhan pemakai 


yang merupakan output dari langkah sebelumnya. ERD merupakan 


model atau abstraksi data yang merupakan fokus utama suatu organisasi. 


Pembuatan ERD dilakukan sebagai berikut. 


l. 


2; 


Tentukan jenis entitas utama pada organisasi. 
Tentukan jenis hubungan utama antar-jenis entitas. 
Tentukan multiplicity jenis hubungan entitas. 


Tentukan atribut atau properti dari jenis entitas dan jenis 


hubungan entitas. 


Buat ERD dengan menggambarkan jenis entitas, hubungannya, 


serta atributnya dengan notasi yang dipilih. 


Periksa dan sempurnakan struktur ERD. 
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Penulisan ERD dapat dilakukan menggunakan beberapa notasi di antara- 
nya notasi UML, Crow's Foot, dan Chen. Buku ini menggunakan notasi 
UML karena notasi UML merupakan bahasa pemodelan umum dan 
standar untuk pengembangan perangkat lunak. Meskipun demikian, 
buku ini juga memberikan penjelasan notasi Crows Foot dan Notasi 


Chen pada Lampiran 1. 


Perhatikan bahwa karena perbedaan metode penemuan fakta yang 
digunakan dan subjektivitas yang tidak bisa dihindari dalam penentuan 
jenis entitas, jenis hubungan entitas, dan atribut, maka ERD yang dibuat 
dapat berbeda dari satu perancang basis data dengan perancang basis data 
yang lain. Yang penting pastikan bahwa ERD tersebut bebas dari perma- 
salahan struktur (Subbab 5.7) dan dapat memenuhi semua kebutuhan 
pemakai (Subbab 7.4). 


5.2 TENTUKAN JENIS ENTITAS 


Jenis Entitas (Entity Type) adalah sekumpulan objek-objek entitas yang 


memiliki karekteristik yang sama dan memiliki keberadaan yang bebas. 


Objek Entitas (Entity Occurence) adalah sebuah objek dari suatu jenis 


entitas yang dapat diidentifikasi secara unik. 


Jenis entitas merepresentasikan "sekumpulan objek" pada dunia nyata 
yang memiliki properti atau karekteristik yang sama. Jenis entitas dapat 
terdiri atas objek-objek entitas yang memiliki keberadaan secara fisik 
maupun abstrak. Sebagai contoh, pada (dunia nyata) rumah sakit dapat 
ditetapkan jenis entitas fisik, yaitu dokter, perawat, dan pasien, dan jenis 


entitas abstrak, yaitu penyakit dan pelayanan. 
HI Contoh 5.1: Jenis Entitas dan Objek Entitas 


Gambar 5.1 memperlihatkan dua jenis entitas, yaitu jenis entitas 


Mahasiswa dan Dosen. Objek-objek entitas Badu, Bona, dan Budi pada 


56 


jenis entitas Mahasiswa memiliki properti yang sama, yaitu atribut nama, 
nim, dan jenis kelamin, sedangkan objek-objek entitas Doni, Dona, dan 
Dono pada jenis entitas Dosen juga memiliki atribut yang sama, yaitu 
atribut nama dan nidn. Setiap objek entitas mahasiswa dan dosen masing- 
masing dapat diidentifikasi secara unik dengan melihat nilai atribut nim 
dan nidn. E 


Lebih jauh, jenis entitas dapat diklasifikasikan sebagai Jenis Entitas Kuat 
(Strong Entity Type) dan Jenis Entitas Lemah (Weak Entity Type). Jenis 
entitas kuat memiliki keberadaan yang tidak bergantung pada keberadaan 
jenis entitas lain, sedangkan jenis entitas lemah memiliki keberadaan yang 


bergantung pada keberadaan jenis entitas lain. 


Jenis Entitas Mahasiswa Jenis Entitas Dosen 


Gambar 5.1 Contoh jenis entitas dan objek entitas 
II Contoh 5.2: Jenis Entitas Kuat dan Lemah 


Berikut contoh jenis entitas kuat dan entitas lemah yang saling ber- 


hubungan: 


e Keberadaan jenis entitas kuat BukuTeks tidak bergantung pada 
jenis entitas lain, termasuk pada jenis entitas EdisiBuku. Sebalik- 
nya, keberadaan jenis entitas lemah EdisiBuku sangat bergantung 
pada keberadaan jenis entitas BukuTeks, Jika tidak ada buku teks 


maka edisi buku tersebut juga tidak akan ada. 
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5.2.1 


Keberadaan jenis entitas kuat Pelanggan tidak bergantung pada 
jenis entitas lain, termasuk pada jenis entitas PembayaranHutang. 
Sebaliknya, keberadaan jenis entitas lemah PembayaranHutang 
sangat bergantung pada keberadaan jenis entitas Pelanggan; 
Pembayaran hutang tidak akan pernah ada jika tidak ada pelang- 
gan yang berhutang. W 


Langkah Pengidentifikasian 


Jenis entitas diidentifikasi dengan membaca dan memahami dokumen 


spesifikasi kebutuhan pemakai, sebagai berikut: 


l. 


Temukan kata benda dan frase kata benda yang menjadi perha- 


tian utama pemakai. Kata benda dan frase kata benda yang dite- 


mukan berpotensi menjadi jenis entitas utama. 


Tuliskan jenis entitas pada kamus data dengan menyertakan 
informasi berupa nama, deskripsi, nama alias (jika ada), dan 
jumlah objek entitas dari masing-masing jenis entitas tersebut. 
Agar mudah dipahami, tuliskan kamus data dalam format tabel 
seperti di bawah ini (contoh dapat dilihat pada Subbab 11.3). 


Jenis Entitas Deskripsi Nama Alias Jumlah Objek Entitas 


5.2.2 


Notasi UML 


Notasi UML untuk jenis entitas adalah empat persegi panjang yang diberi 


label dengan nama jenis entitas pada notasi tersebut. Jika nama tersebut 


terdiri atas dua kata atau lebih, penulisannya tidak menggunakan spasi di 


antara kata, dan setiap huruf awal dimulai dengan huruf besar. Gam- 


bar 5.2 memperlihatkan contoh penulisan notasi jenis entitas. 
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Gambar 5.2 Jenis entitas Mahasiswa dan MataKuliah 


5.3 TENTUKAN JENIS HUBUNGAN ENTITAS 


Jenis Hubungan Entitas (Relationship Type) adalah sekumpulan asosiasi 
atau hubungan di antara objek entitas yang menjadi fokus utama pada 


perancangan basis data. 


Objek Hubungan Entitas (Relationship Type Occurrence) adalah objek 
dari asosiasi atau jenis hubungan entitas yang dapat diidentifikasi secara 
unik. 


Jenis hubungan entitas merepresentasikan "sekumpulan hubungan di 
antara objek-objek entitas" (pada dunia nyata), di mana hubungan ter- 


sebut memiliki properti atau karekteristik yang sama. Setiap jenis hu- 


bungan entitas memiliki nama yang mendeskripsikan fungsi dari jenis 
hubungan entitas tersebut. Setiap jenis hubungan entitas juga memiliki 
arah dan setiap hubungan dapat dilihat (dibaca) dari dua arah yang ber- 


lawanan. 


E Contoh 5.3: Jenis dan Objek Hubungan Entitas 


Jenis Hubungan Entitas 
DiajarOleh 


Jenis Entitas Dosen 


Jenis Entitas Mahasiswa PA i N 
/ diajar oleh N 


“/diajar oleh 3Y 


E AGE ea Mata 


Gambar 5.3 Contoh jenis dan objek hubungan entitas 
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Gambar 5.3 memperlihatkan contoh jenis hubungan entitas DiajarOleh 
yang mengasosiasikan jenis entitas Mahasiswa dan Dosen. Ada tiga objek 
hubungan entitas, yaitu "diajar oleh 1" yang menghubungkan Badu-Doni, 
"diajar oleh 2" yang menghubungkan Bona-Dona, dan "diajar oleh 3" 


yang menghubungkan Budi-Dono. 


Jenis hubungan entitas DiajarOleh dapat dilihat dari arah berlawanan, 
yaitu dari jenis entitas Dosen ke Mahasiswa dengan nama jenis hubungan 


entitas Mengajar (Dosen Mengajar Mahasiswa). W 


5.5.1 Langkah Pengidentifikasian 


Sama seperti jenis entitas, jenis hubungan entitas diidentifikasi dengan 
membaca dan memahami dokumen spesifikasi kebutuhan pemakai, seba- 


gai berikut. 


1. Temukan kata kerja atau frase kata kerja yang menjadi perhatian 


utama pemakai. 


2. Untuk setiap jenis entitas yang telah diidentifikasi pada langkah 
sebelumnya, periksa apakah terdapat hubungan yang menjadi 
fokus utama pemakai, baik secara eksplisit maupun secara 
implisit. 

3. Tuliskan jenis hubungan entitas pada kamus data dengan 
menyertakan informasi berupa nama-nama jenis entitas beserta 
nama jenis hubungan entitas yang mengasosiasikan jenis entitas 


tersebut. Contoh penulisan ini dapat dilihat pada Subbab 11.3. 


Jenis Entitas Jenis Hubungan Jenis Entitas 


Umumnya, jenis hubungan entitas menghubungkan dua jenis entitas. 


Jenis hubungan entitas ini disebut dengan Jenis Hubungan Entitas Biner. 
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Misalnya, jenis hubungan entitas DiajarOleh pada Gambar 5.3 merupa- 
kan jenis hubungan entitas biner karena jenis hubungan entitas ini meng- 


asosiasikan dua jenis entitas, yaitu Dosen dan Mahasiswa. 


Bentuk jenis hubungan entitas lain adalah jenis hubungan entitas tunggal 
(recursive/unary relationship type) dan jenis hubungan entitas kompleks 
(complex relationship type). Jenis Hubungan Entitas Tunggal menghu- 
bungkan satu jenis entitas yang sama, sedangkan Jenis Hubungan Entitas 
Kompleks menghubungkan lebih dari dua jenis entitas. Misalnya, jenis 
hubungan entitas Pembinaan di antara sesama dosen pada Gambar 5.4 
merupakan contoh jenis hubungan entitas tunggal, di mana seorang 


dosen (senior) dapat membina satu atau beberapa dosen (junior). 


53.2 Notasi UML 


Notasi UML untuk jenis hubungan entitas adalah garis yang menghu- 
bungkan jenis entitas, dan garis tersebut diberi label kata kerja (transitif 
atau intransitif) dengan disertai mata panah sebagai penunjuk arah 
hubungan. Jika nama jenis hubungan entitas terdiri atas dua kata atau 
lebih, maka nama tersebut dituliskan tanpa menggunakan spasi pemisah 


di antara kata, dan huruf awal setiap kata dituliskan dengan huruf besar. 


E Contoh 5.4: Notasi Jenis Hubungan Entitas 


Membina Pr 


DosenSenior 
DiajarOleh > 


Mahasiswa 


Gambar 5.4 Jenis hubungan entitas DiajarOleh dan Membina 


DosenJunior 


Gambar 5.4 memperlihatkan contoh jenis hubungan entitas Biner 


DiajarOleh yang mengasosiasikan jenis entitas Mahasiswa dan Dosen, 
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serta jenis hubungan entitas tunggal Membina yang secara berulang 


menghubungkan satu jenis entitas Dosen. 


Jenis entitas Dosen memiliki Nama Peran (role name) DosenSenior dan 
DosenJunior pada kedua ujung garis. Fungsi nama peran adalah mem- 
berikan penjelasan lebih lanjut tentang jenis hubungan entitas. ERD ini 
dapat dibaca sesuai dengan arah hubungan sebagai berikut: "Mahasiswa 


diajar oleh dosen dan dosen senior dapat membina dosen junior". W 


5.4 TENTUKAN MULTIPLICITY 


Multiplicity adalah deskripsi tentang jumlah suatu objek entitas yang 


mungkin dapat diasosiasikan dengan satu objek entitas lain. 


Pada contoh jenis hubungan entitas DiajarOleh pada Gambar 5.4, satu 
objek entitas Mahasiswa dapat diajar oleh satu atau beberapa objek entitas 
Dosen, dan satu objek entitas dosen dapat mengajar satu atau lebih objek 


entitas mahasiswa. 


Multiplicity merupakan suatu ketentuan (constraint) yang mengatur 
hubungan di antara objek-objek entitas. Oleh karena itu, multiplicity 


merupakan kebijakan atau aturan bisnis (business rule) yang ditetapkan 


oleh pemakai atau organisasi, yang dapat berbeda dari satu organisasi 


dengan organisasi lain. 
HI Contoh 5.5: Multiplicity Jenis Hubungan Entitas Merawat 


Misalnya, suatu rumah sakit dapat memiliki kebijakan bahwa seorang 
dokter hanya dapat merawat maksimum 10 orang pasien per hari, 
sedangkan kebijakan pada rumah sakit lain mungkin berbeda, yaitu 


maksimum 15 orang pasien per hari. W 


Lebih lanjut, multiplicity dapat dibagi menjadi dua batasan atau aturan, 


yaitu: 
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1. Batasan Kardinalitas (Cardinality Constraint) yang menentukan 


jumlah maksimum objek entitas lain yang dapat berasosiasi 


dengan suatu objek entitas tertentu. 


2. Batasan Partisipasi (Participation Constraint) yang menentukan 


apakah semua atau sebagian objek entitas berpartisipasi pada 


suatu jenis hubungan entitas. 


Partisipasi dikatakan Wajib (mandatory atau full) jika semua objek entitas 
berpartisipasi pada jenis hubungan entitas. Dan partisipasi dikatakan 
Opsional atau Partial, jika tidak semua objek entitas berpatisipasi pada 


jenis hubungan entitas. 


HI Contoh 5.6: Batasan Kardinalitas dan Partisipasi 

Misalnya, pada jenis hubungan entitas Merawat, seorang dokter dapat 
merawat 0 pasien (atau tidak merawat satu orang pasien pun) dan mak- 
simum lebih dari 1 pasien (banyak). Pada contoh ini, batasan kardinalitas 
jenis hubungan entitas Merawat terhadap jenis entitas dokter adalah 


banyak, dan batasan partisipasinya bersifat opsional (Gambar 5.5). 


Dokter Tuti dan Teti masing-masing merawat dua orang pasien (banyak), 
sedangkan Dokter Tito tidak merawat satu orang pasien pun. Pada 
contoh ini, Dokter Tito tidak berpartisipasi dalam jenis hubungan entitas 


Merawat karena dia tidak terasosiasi pada seorang pasien pun. HH 


Jenis Hubungan Entitas 
“Merawat” 


Jenis Entitas “Dokter” Jenis Entitas “Pasien” 


Gambar 5.5 Contoh batasan kardinalitas dan partisipasi 
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Karena jenis hubungan entitas dapat dilihat dari dua arah berlawanan, 


maka batasan kardinalitas dan partisipasi dapat juga diterapkan pada arah 
berlawanan. Misalnya pada contoh di atas, jika dilihat dari arah ber- 
lawanan, terdapat batasan bahwa seorang pasien wajib dirawat minimum 
oleh seorang dokter karena semua pasien mempunyai dokter yang mera- 
watnya (batasan partisipasi bersifat wajib), dan maksimum dirawat oleh 
lebih dari satu orang dokter, yaitu pada kasus pasien Dedi (batasan kar- 


dinalitas banyak). 


Perbandingan kardinalitas yang dilihat dari dua arah hubungan disebut 
dengan Rasio Kardinalitas (Cardinality Ratio) atau Derajat Hubungan 
(Relationship Degree). Pada contoh di atas, karena seorang dokter dapat 
merawat maksimum banyak pasien dan seorang pasien dapat dirawat 
maksimum oleh banyak dokter, maka rasio kardinalitasnya adalah many- 
to-many (N:N). Perhatikan bahwa nilai kardinalitas yang lebih besar dari 
satu dikatakan banyak (many) dengan simbol N'. 


Terdapat tiga jenis rasio kardinalitas, yaitu: 
1. One-to-One (1:1), jika nilai kardinalitas pada kedua arah 1. 


2. One-to-Many (I:N) atau Many-to-One (N:1), jika nilai kardi- 


nalitas pada salah satu arah 1 dan arah lainnya banyak (N). 


3.  Many-to-Many (N:N), jika nilai kardinalitas pada kedua arah 
banyak (N). 
SALA Langkah Pengidentifikasian 
Pengidentifikasian multiplicity dapat dilakukan sebagai berikut: 


1. Perhatikan penjelasan rinci setiap jenis hubungan entitas pada 
kamus data dan temukan nilai kardinalitas dan partisipasinya. 


Jika nilai tersebut tidak dapat ditemukan atau tidak lengkap, 


1 Simbol lain yang umumnya digunakan untuk many adalah "" atau ‘M’. 


64 


mintalah penjelasan lebih lanjut kepada pemakai, dan tambahkan 


informasi tersebut pada dokumen spesifikasi. 


2. Dokumentasikan semua jenis hubungan entitas lengkap dengan 
multiplicity-nya dengan mengisi tabel berikut. Ini melengkapi 
kamus data dengan penambahan rasio kardinalitas pada tabel 


jenis hubungan entitas. Contoh penulisan ini dapat dilihat pada 


Subbab 11.3. 
Jenis Rasio Jenis Hubungan Rasio Jenis 
Entitas Kardinalitas Entitas Kardinalitas Entitas 


542 Notasi UML 


Nilai multiplicity dituliskan di kedua ujung garis jenis hubungan entitas 
dalam bentuk "nilai partisipasi..nilai kardinalitas". Nilai partisipasi 
ditulis 0 untuk jenis hubungan opsional. Jenis hubungan entitas dapat 


dibaca dalam dua arah berdasarkan multiplicity tersebut. 


II Contoh 5.7: Multiplicity dan Rasio Kardinalitas 


Gambar 5.6 Multiplicity jenis hubungan entitas Merawat 


Gambar 5.6 memperlihatkan contoh jenis hubungan entitas Merawat 


yang mengasosiasikan jenis entitas Dokter dan Pasien, sebagai berikut: 


1. Multiplicity dengan arah jenis entitas Dokter ke Pasien diletakkan 
pada ujung garis yang berseberangan dengan jenis entitas Dokter, 
dan dibaca "Seorang Dokter dapat merawat minimum 0 orang 


pasien dan maksimum banyak (N) pasien". 
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2. Multiplicity dengan arah jenis entitas Pasien ke Dokter diletakkan 
pada ujung garis yang berseberangan dengan jenis entitas Pasien 
dan dibaca: "Seorang Pasien dapat dirawat oleh minimum 1 


orang dokter dan maksimum banyak (N) dokter". 


3. Rasio kardinalitas jenis hubungan tersebut adalah many-to-many 


(N:N) yang didapat dari nilai kardinalitas di kedua ujung garis. Ii 


Nilai partisipasi dan kardinalitas dapat dituliskan dalam angka tertentu 


jika nilai minimum dan maksimum diketahui. 
II Contoh 5.8: Kardinalitas dalam Jumlah Tertentu 


Perhatikan Gambar 5.7. Pada arah sesuai dengan mata panah dibaca 
"Seorang penjaga toko dapat melayani minimal 1 pembeli dan maksimal 
20 pembeli", sedangkan dalam arah yang berlawanan dibaca "Seorang 


pembeli hanya dapat dilayani oleh 1 penjaga toko saja". I 


Melayani p> 
PenjagaToko — Aan Pembeli 
1343 1.20; 
k x 


kardinalitas 


Gambar 5.7 Multiplicity jenis hubungan entitas Melayani 


5.5 TENTUKAN ATRIBUT 


Atribut (Attribute) adalah properti atau karekteristik dari jenis entitas 


dan jenis hubungan entitas. 


Atribut menyimpan nilai-nilai yang mendeskripsikan objek entitas dan 
objek hubungan entitas. Nilai-nilai tersebut merupakan bagian utama 


data yang akan disimpan dan dikelola pada basis data”. 


? Secara umum, atribut pada jenis entitas adalah sama dengan kolom pada tabel (lihat 
Bab 6 Pemetaan ERD). 
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Pada jenis entitas dan hubungan entitas yang diperlihatkan pada Gam- 


bar 1.1 dapat diberikan atribut-atribut, sebagai berikut: 


Jenis entitas Mahasiswa dideskripsikan oleh atribut nama, nim, 


jenis kelamin, dan kode mata kuliah. 


Jenis entitas Dosen dideskripsikan oleh atribut nama, nidn, dan 
kode mata kuliah. 


Jenis entitas Mata Kuliah dideskripsikan oleh atribut nama, kode, 


dan sks. 


Jenis hubungan entitas Mengajar dapat diberikan atribut tahun 
dan semester yang mendeskripsikan kapan seorang dosen meng- 


ajar suatu mata kuliah. 


Data yang merupakan nilai-nilai atribut dari tiga orang mahasiswa, tiga 


orang dosen, serta tiga mata kuliah inilah yang merupakan data utama 


yang akan disimpan pada basis data seperti pada tabel-tabel di Gambar 


1.1. 


Lebih lanjut, atribut dapat dibagi atas beberapa jenis: 


1. 


Atribut Sederhana (Simple Attribute), yaitu atribut yang memi- 


liki komponen tunggal, seperti atribut umur dan jenis kelamin. 


Atribut Campuran (Composite Attribute), yaitu atribut yang 
terdiri atas beberapa atribut sederhana sebagai komponen penyu- 
sunnya, seperti atribut alamat yang dapat terdiri atas sub-atribut 


jalan, nama kota, dan kode pos. 


Atribut Bernilai Tunggal (Single-Valued Attribute), yaitu atribut 
yang hanya dapat menyimpan satu nilai pada setiap objek entitas 
dan objek hubungan entitas, misalnya atribut umur, nim, dan 


nidn. 
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4. Atribut Bernilai Jamak (Multi-Valued Attribute), yaitu atribut 


yang memiliki nilai lebih dari satu. Misalnya, jika seorang staf 
dapat memiliki dua nomor handphone, maka atribut tersebut 


pada jenis entitas staf merupakan atribut bernilai jamak. 


Atribut Turunan (Derived Attribute), yaitu atribut yang nilainya 
dihitung berdasarkan nilai atribut atau komponen lain yang 
berhubungan dengan atribut tersebut. Misalnya, atribut umur 
pada jenis entitas Mahasiswa yang dihitung berdasarkan tanggal 


lahir dan tanggal saat ini. 


Atribut Kunci (Key Attribute), yaitu atribut yang nilainya dapat 
membedakan secara unik objek entitas. Atribut kunci berhu- 
bungan dengan candidate key yang telah dijelaskan pada Bab 1. 
Misalnya, atribut nim dan nidn yang masing-masing terdapat 
pada jenis entitas Mahasiswa dan Dosen merupakan atribut 


kunci. 


Atribut kunci dapat terdiri atas gabungan dua atribut atau lebih, di mana 


nilai atribut-atribut tersebut secara bersama-sama membedakan secara 


unik objek entitas. Gabungan atribut ini disebut dengan Kunci Komposit 


(composite key). 


HI Contoh 5.9: Kunci Komposit 
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Grade 


gradeid | kodeMakul | nim | grade | idDosen 


gr001 mk001 mhs001 
gr002 mk001 mhs002 fe 
gr003 mk002 mhs001 fee | 


Gambar 5.8 Kunci komposit pada objek entitas Grade 


Gambar 5.8 memperlihatkan objek entitas Grade yang disimpan pada 
tabel. Setiap tuple mewakili satu objek entitas. Jenis entitas Grade 
memiliki lima atribut, yaitu gradeld, kodeMakul, nim, grade, dan 
idDosen pengajar. Salah satu atribut kunci pada jenis entitas Grade adalah 
atribut kodeMakul dan nim yang merupakan composite key. Nilai 
composite key ini secara bersama-sama dapat membedakan masing- 
masing objek entitas karena setiap nim pasti hanya memiliki satu grade 
untuk setiap mata kuliah yang telah diambil. Perhatikan bahwa atribut 
kodeMakul saja atau nim saja tidak dapat dijadikan atribut kunci karena 


masing-masing atribut memiliki nilai duplikat (atau tidak unik). 


Suatu jenis entitas dapat memiliki lebih dari satu atribut kunci. Sekum- 
pulan atribut kunci pada suatu jenis entitas disebut dengan kunci kan- 
didat (candidate key). Pada jenis entitas Grade terdapat dua candidate 
key, yaitu (1) atribut gradeld, dan (2) atribut kodeMakul dan nim. E 


Jika menemukan lebih dari satu candidate key, pilihlah salah satu atribut 
kunci untuk dijadikan primary key, dan selebihnya sebagai kunci alter- 
natif (alternate key). Jika hanya ada satu atribut kunci, maka atribut kunci 


tersebut satu-satunya pilihan untuk dijadikan primary key. 


Berikut beberapa kriteria pemilihan atribut primary key dari candidate 
key yang ada. 


e Pilihlah atribut kunci yang nilainya jarang berubah. Misalnya, 


atribut nip dan nim. 


e Pilihlah atribut kunci yang selalu memiliki nilai yang valid (atau 
tidak akan pernah memiliki null). Misalnya, atribut nip dan nim 


yang selalu memiliki nilai atau tidak pernah kosong. 


e Pilihlah atribut kunci yang memiliki jumlah atribut penyusun 


minimal. Misalnya, pada jenis entitas Grade di atas pilihlah 
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atribut gradeld daripada kodeMakul, dan nim sebagai atribut 
primary key. 


e Pilihlah atribut kunci yang memiliki jumlah karakter yang 
minimum. Misalnya, pilihlah nim yang memiliki 10 karakter 
dibandingkan alamat yang memiliki 50 karakter (jika alamat 


unik). 


Perhatikan bahwa suatu atribut dapat sekaligus digolongkan pada dua 
jenis atribut atau lebih. Misalnya, atribut umur merupakan atribut tu- 


runan, bernilai tunggal, dan sederhana. 


Penentuan suatu atribut apakah sebagai atribut sederhana atau atribut 
campuran bergantung pada kebutuhan pemakai terhadap data. Misalnya, 
jika pemakai membutuhkan pencarian alamat pelanggan berdasarkan 
kode pos atau nama kota, maka atribut alamat pada jenis entitas 
Pelanggan sebaiknya merupakan atribut campuran. Tetapi jika hal ter- 
sebut tidak dibutuhkan maka cukup menetapkan atribut alamat sebagai 


atribut sederhana. 


5.5.1 Langkah Pengidentifikasian 


Atribut diidentifikasi dengan membaca dan memahami dokumen spesi- 


fikasi kebutuhan pemakai, sebagai berikut. 


1. Seperti pada saat pengidentifikasian jenis entitas, atribut diiden- 
tifikasi dengan melihat kata benda dan frase kata benda yang 
merupakan properti, kualitas, pengenal, atau karekteristik dari 


salah satu jenis entitas atau hubungan entitas pada kamus data. 


2. Untuk setiap jenis entitas x dan jenis hubungan entitas y, ajukan 
pertanyaan "Informasi apa yang diperlukan oleh pemakai ter- 
hadap x atau y?". Informasi tersebut merupakan atribut untuk x 


atau y. Jawaban pertanyaan ini seharusnya dapat ditemukan pada 


70 


dokumen spesifikasi, tetapi jika tidak ditemukan, tanyakan lang- 
sung kepada pemakai. Misalnya, untuk jenis entitas Mahasiswa 
dapat ditanyakan kepada pemakai informasi apa saja yang 


dibutuhkan tentang mahasiswa pada saat aplikasi basis data 


digunakan. 

3. Untuk masing-masing atribut yang telah teridentifikasi tentukan: 

a. Domain, yaitu nilai-nilai yang mungkin untuk atribut ter- 
sebut. 

b. Jenis, yaitu salah satu dari enam jenis atribut di atas. 

c. Nilai awalnya jika ada. 

d. Boleh null atau tidak. 

4. Dokumentasikan seluruh atribut pada kamus data dengan me- 
nyertakan informasi: nama jenis entitas, nama atribut, deskripsi, 
domain, nama alias, jenis atribut, nilai awal atribut, dan boleh 
tidaknya null. Tuliskan dalam format tabel agar mudah 
dipahami. Contoh penulisan kamus data ini dapat dilihat pada 
Subbab 11.3. 

Nama Nama Deskripsi Domain Alias Jenis Nilai Null 
Jenis Atribut Atribut Awal 
Entitas 

552 Notasi UML 


Untuk menuliskan atribut pada jenis entitas, notasi segi empat jenis 


entitas dibagi menjadi dua bagian. Di mana pada bagian atas adalah nama 


jenis entitas, dan bagian bawah adalah daftar nama atribut dari jenis 


entitas tersebut. 


Ketentuan penulisan atribut adalah sebagai berikut: 
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e Awal kata pada nama atribut dituliskan dalam huruf kecil, dan 
awal kata selanjutnya dalam huruf besar. Misalnya, namaAwal 


dan namaAkhir. 


e Atribut primary key dituliskan pada urutan paling atas diikuti 
notasi "{PK}". Misalnya, nim {PK}. 


e Atribut selain dari primary key dituliskan di bawah atribut kunci. 


e Atribut campuran dituliskan berikut dengan nama-nama atribut 


sederhana penyusunnya. 


e Atribut turunan dituliskan dengan menambahkan karakter '/' 


pada awal nama. 


e Atribut bernilai jamak dituliskan dengan menuliskan "[1..n]" 


pada akhir nama, di mana n adalah jumlah maksimum nilai. 


e Atribut sederhana dan atribut bernilai tunggal dituliskan tanpa 


menambahkan notasi lain. 


Atribut untuk jenis hubungan entitas dituliskan sama dengan cara 
penulisan atribut jenis entitas, hanya saja pada kotak nama entitas di- 
biarkan kosong, dan di antara atribut tersebut dan jenis hubungan entitas 


ditarik garis putus-putus. 


E Contoh 5.10: Penulisan Atribut pada Jenis Entitas & Hubungan 
Entitas 


Gambar 5.9 memperlihatkan contoh penulisan atribut pada jenis entitas 
Dokter dan Pasien, serta pada jenis hubungan entitas Merawat. Per- 
hatikan bahwa idDokter dan kodePasien masing-masing merupakan 
primary key, noHP adalah atribut bernilai jamak, alamat adalah atribut 


campuran, dan lamaBekerja dan umur adalah atribut turunan. E 
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Merawat P 
Dokter Pasien 


idDokter {PK} kodePasien {PK} 
nama nama 


Spesialis tglLahir 


tgiBekerja tgiRawat /umur 


IlamaBekerja jenisTindakan alamat 

noHp [1..2] jalan 
kota 
kodePos 


Gambar 5.9 Atribut jenis entitas dan hubungan entitas 


5.6 GAMBARKAN ERD 


Setelah pengidentifikasian jenis entitas, jenis hubungan entitas, dan 
atribut, langkah selanjutnya adalah menggambarkan ERD lengkap ber- 
dasarkan kamus data yang telah dibuat. Jika ERD cukup kompleks, maka 
cukup dituliskan atribut kunci (primary key) saja pada setiap jenis entitas. 
Penggambaran ERD dapat menggunakan aplikasi editor UML, misalnya 
ArgoUML, StarUML, atau Microsoft PowerPoint/Visio?. 


5.7 PERBAIKI STRUKTUR ERD 


Setelah pembuatan ERD, langkah selanjutnya adalah memeriksa struktur 
ERD dan memperbaikinya jika ditemukan permasalahan. Pemeriksaan 
dilakukan dengan mengidentifikasi keberadaan masalah redudansi dan 


perangkap pada struktur ERD. 


Terdapat dua masalah perangkap: Fan Trap dan Chasm Trap. Kedua 
masalah ini dapat menimbulkan kesalahpahaman tentang makna objek 


jenis hubungan entitas sehingga harus dihilangkan. 


3 http://en.wikipedia.org/wiki/List of Unified Modeling Language tools menyediakan 
daftar nama editor UML. 


73 


Perbaikan terhadap dua permasalahan struktur ERD dilakukan dengan 
memodifikasi struktur diagram, baik dengan cara menghilangkan jenis 
hubungan entitas, menambah jenis hubungan entitas baru, atau meng- 


ubah susunan jenis entitas. 


57 Menghilangkan Redundansi Hubungan 


Suatu jenis hubungan entitas dikatakan redundan (berlebihan) jika infor- 
masi yang diberikan oleh jenis hubungan entitas tersebut dapat diperoleh 


melalui jenis hubungan entitas yang lain. 


Jenis hubungan entitas yang rendundan, selain menyebabkan ERD tidak 
minimal (sehingga sulit untuk dipahami), juga menyebabkan redudansi 
data pada basis data. Redundansi data adalah data yang sama disimpan 
berulang pada basis data sehingga mengakibatkan pemborosan tempat 
penyimpanan data. Oleh karena itu, jenis hubungan entitas rendundan 
harus diidentifikasi dan dihapus dari ERD. 


E Contoh 5.11: Jenis Hubungan Entitas Redundan 


Perhatikan Gambar 5.10. Terdapat dua informasi yang masing-masing 


dapat diperoleh melalui dua jalur yang berbeda. 


1. Informasi training yang telah diselesaikan oleh seorang staf dapat 
diperoleh secara langsung melalui jenis hubungan entitas 
Menyelesaikan dan secara tidak langsung melalui jenis hubungan 


entitas Memiliki dan Membuktikan. 


2. Informasi sertifikat yang dimiliki oleh seorang staf dapat 
diperoleh secara langsung melalui jenis hubungan entitas 
Memiliki, dan secara tidak langsung melalui jenis hubungan 


entitas Menyelesaikan dan Membuktikan. 
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Memiliki B> 


staf 


sertifikat 


idStaf (PK) nomor {PK} 


nama tahun 


alamat predikatLulusan 


kode (PK) 


tahun 


namaLembaga 


Menyelesaikan 


v 


Membuktikan 
v 


namaTraining 


Gambar 5.10 Contoh hubungan entitas yang redundan 


Penentuan apakah suatu jenis hubungan entitas redundan dilakukan 
dengan melihat jenis hubungan entitas mana yang lebih dipentingkan 
dan/atau yang lebih sering diakses oleh pemakai. Pada contoh ke-2, jika 
pemakai lebih mementingkan informasi sertifikat seorang staf dan 
informasi ini lebih sering dibutuhkan, maka jenis hubungan entitas 
Menyelesaikan adalah redundan dan dapat dihapus. Sebaliknya, pada 
contoh ke-1, jika pemakai lebih mementingkan info training yang telah 
diikuti oleh seorang staf dan informasi ini lebih sering diakses oleh 
pemakai, maka jenis hubungan entitas Memiliki adalah redundan dan 


dapat dihapus dari diagram. 


Perlu diperhatikan bahwa jenis hubungan entitas Membuktikan tidak 
dapat dihapus dari diagram karena asosiasi di antara sertifikat dan 
training tidak bisa atau sulit didapat secara tidak langsung dari jenis 
hubungan entitas Menyelesaikan dan Memiliki. Misalnya, jika seorang 
karyawan telah mengikuti sejumlah training dan karyawan tersebut 
memiliki sejumlah sertifikat, maka sulit mengasosiasikan training dan 
sertifikat jika tidak ada asosiasi yang eksplisit, di antara sertifikat dan 


training. W 
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57.2 Menghilangkan Fan Trap 


Fan Trap adalah permasalahan struktur ERD yang mengakibatkan ter- 
jadinya ketidakpastian hubungan di antara dua objek entitas dari dua 


jenis entitas yang berbeda. 


Fan trap harus dihilangkan dari diagram karena akan mengakibatkan 
pemberian informasi yang tidak pasti (ambigu) kepada pemakai, pada 
saat pengambilan data dari basis data. Fan trap terjadi jika memenuhi dua 


syarat berikut: 


1. Sebuah jenis entitas pusat memiliki hubungan secara langsung ke 


dua atau lebih jenis entitas lain. 


2. Hubungan dari jenis entitas pusat ke dua jenis entitas lain 
tersebut adalah I:N. 


Fan trap dihilangkan dengan merestrukturisasi jenis hubungan entitas 


sehingga salah satu kondisi di atas tidak terpenuhi. 
HI Contoh 5.12: Fan Trap dan Cara Menghilangkannya 


Perhatikan ERD bank pada Gambar 5.11. Jenis entitas (pusat) Bank dapat 
memiliki satu orang staf atau lebih, dan dapat mengoperasikan satu 
cabang atau lebih. Setiap staf terdaftar hanya pada satu bank saja, dan 
ditempatkan pada salah satu cabang bank tersebut. Setiap cabang hanya 


dioperasikan oleh satu bank tertentu saja. 


& Memiliki Mengoperasikan $> 
Staf Bank ——E- Cabang 
1.1 (1..Nj 
idStaf (PK) Hi kodeBank {PK} "s7 kodeCab {PK} 
nama namaBank namaCab 
tglLahir alamatBank alamatCab 


Gambar 5.11 Contoh fan trap pada ERD Bank 
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Dari gambar dapat dilihat bahwa ERD tersebut memenuhi syarat 
terjadinya fan trap, yaitu terdapat hubungan I:N dari jenis entitas Bank ke 
Staf, dan I:N dari jenis entitas Bank ke Cabang. Dengan adanya fan trap 
maka pertanyaan berikut tidak dapat dijawab dengan pasti: "Di cabang 


manakah seorang staf ditempatkan?" 


Untuk melihat ketidakpastian informasi, perhatikan gambar detail objek 
entitas dan objek hubungan entitas pada Gambar 5.12. Pertanyaan: Di 
cabang manakah "Dadi" dan "Dona" ditempatkan oleh "Bank A"? Apakah 
di Cabang "Cab A1" atau "Cab A2"? tidak dapat dijawab dengan pasti, 
karena "Bank A" memiliki dua cabang, sedangkan seorang staf hanya 


dapat ditempatkan pada satu cabang. 


Jenis Entitas Staf Jenis Entitas Bank Jenis Entitas Cabang 


Hubungan Entitas Hubungan Entitas 
Memiliki Mengoperasikan 


Gambar 5.12 Objek entitas dan hubungan entitas ERD bank 


Permasalahan fan trap pada contoh di atas dapat dihilangkan dengan 
menghapus jenis hubungan entitas Memiliki di antara jenis entitas Bank 
dan Staf, dan membuat jenis hubungan entitas baru Mempekerjakan yang 


menghubungkan jenis entitas Cabang dan Staf (Gambar 5.13). 


Mengoperasikan Pb Mempekerjakanpp 
Bank Staf 
1..1 1..N 1A 1.N 
kodeBank (PK) kodeCab (PK) idStaf (PK) 
namaBank namaCab nama 
alamatBank alamatCab tgiLahir 


Gambar 5.13 ERD bank setelah direstrukturisasi 
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Gambar 5.14 memperlihatkan bahwa dengan melakukan restrukturisasi 
diagram maka informasi nama cabang untuk masing-masing staf dapat 
diketahui dengan pasti: "Dadi" ditempatkan di Cabang "Cab A1" dan 
"Dona" ditempatkan di Cabang "Cab A2". E 


Jenis Entitas Bank Jenis Entitas Cabang Jenis Entitas Staf 


Jenis Hubungan Entitas Jenis Hubungan Entitas 
Mengoperasikan Mempekerjakan 


Gambar 5.14 Objek entitas dan jenis hubungan entitas ERD bank 
setelah direstrukturisasi 


573 Menghilangkan Chasm Trap 


Chasm Trap adalah ketidaknormalan struktur ERD yang mengakibatkan 
hilangnya hubungan di antara dua objek entitas (dari jenis entitas yang 


berbeda) yang seharusnya tergambar pada diagram. 


Chasm trap harus dihilangkan dari diagram karena mengakibatkan 
ketidakmampuan basis data untuk memberikan informasi yang seha- 


rusnya ada. Chasm trap terjadi jika memenuhi dua syarat berikut: 


1. Sebuah jenis entitas pusat memiliki hubungan secara langsung ke 


dua atau lebih jenis entitas lain. 


2. Salah satu dari jenis hubungan entitas tersebut dalam arah ke 


jenis entitas pusat memiliki batasan partisipasi opsional. 


Chasm trap dihilangkan dengan menambahkan satu jenis hubungan 


entitas baru di antara dua jenis entitas yang hubungannya terputus. 
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E Contoh 5.13: Chasm Trap dan Cara Menghilangkannya 


Gambar 5.15 memperlihatkan contoh chasm trap yang terjadi pada 
sebuah perusahaan yang memiliki beberapa kantor cabang. Setiap kantor 
cabang merekrut satu office boy (OB) atau lebih, dan setiap OB ditugas- 


kan pada satu bagian atau lebih pada kantor cabang tertentu. 


Merekrut p> DitugaskanKe > 
KantorCabang OfficeBoy —— Bagian 
1..1 1..N 10.1 5 1.N 
kodeCab (PK) kodeOB (PK) ia kodeBag (PK) 
namaCab nama namaBag 
alamatCab tglLahir gedung 


Gambar 5.15 Chasm trap pada ERD kantor cabang 


Perlu dicatat bahwa tidak semua bagian memiliki OB, dan oleh karena itu, 
partisipasi bagian adalah opsional terhadap kepemilikan OB. Akibat dari 
partisipasi opsional ini, jika suatu bagian tidak memiliki OB maka tidak 


dapat diketahui di kantor cabang yang mana bagian tersebut berada. 


Gambar 5.16 memperlihatkan contoh objek entitas dan hubungan entitas 
dari ERD pada Gambar 5.15. Kantor Cabang "Jkt" merekrut satu orang 
OB dan Kantor Cabang "Bdg" merekrut dua orang OB. "Yadi" ditem- 
patkan pada Bagian "Sales" dan "Yona" serta "Yudu" pada Bagian 


"Finance". 
Jenis Entitas Jenis Entitas Jenis Entitas 
Bagian 


Office Boy 


Kantor Cabang 


Doais 


pere mier aa EID ) Finance 
P Cann 


Kasir 
) 


Hubungan Entitas Hubungan Entitas 
Merekrut Ditugaskan 


Gambar 5.16 Objek entitas dan hubungan entitas pada ERD 
cabang perusahaan 
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Dari diagram tersebut dapat diketahui bahwa Bagian Sales dan Finance 
masing-masing berada pada Kantor Cabang "Jkt dan Bdg" dengan 
menelusuri dalam arah berlawanan dari hubungan entitas "Ditugaskan" 
dan "Merekrut". Berbeda dengan kondisi ini, Bagian Kasir tidak dapat 
ditetapkan berada pada kantor cabang yang mana, karena tidak ada satu 
orang OB pun yang ditempatkan pada bagian ini (sehingga jalur ter- 
putus). 

Permasalahan chasm trap pada contoh di atas dapat dihilangkan dengan 


menambahkan jenis hubungan entitas (baru) Memiliki di antara jenis 


entitas KantorCabang dan Bagian (Gambar 5.17). 


Merekrut p> Ditugaskan Pr 
KantorCabang OfficeBoy = Bagian 


kodeCab {PK} kodeOB {PK} kodeBag {PK} 


namaCab nama namaBag 


alamatCab tglLahir gedung 


1..1 Memiliki P» 1..N 


Gambar 5.17 ERD kantor cabang setelah direstrukturisasi 


Gambar 5.18 memperlihatkan bahwa dengan melakukan restrukturisasi 
diagram Gambar 5.17 maka informasi keberadaan semua cabang (baik 
yang memiliki OB maupun tidak) dapat ditelusuri secara langsung 
melalui jenis hubungan entitas Memiliki. Perhatikan bahwa jenis hu- 
bungan entitas Memiliki tidak redundan, karena hubungan ini diperlukan 


sebagai penghubung informasi yang terputus. W 
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Jenis Entitas Jenis Entitas Jenis Entitas 
KantorCabang OfficeBoy Bagian 


Jenis Hubungan 


Jenis Hubungan 
Entitas Merekrut 


Entitas Ditugaskan 


Hubungan Entitas 
Memiliki 


Gambar 5.18 Objek entitas dan objek hubungan entitas pada ERD 
kantor cabang setelah direstrukturisasi 


5.8 


RINGKASAN MINDMAP 


JE kuat 


tipe 


JE lemah 
1. tentukan jenis entitas (JE) utama 


temukan kata benda 


langkah identifikasi: 
tuliskan JE pada kamus data 


JHE tunggal 
tipe: JHE biner 
JHE kompleks 


2. tentukan jenis hubungan 
temukan kata kerja 


entitas (JHE) utama 
periksa setiap entitas 


langkah identifikasi: & lihat hubungannya 


tulis JHE pada kamus data 6 


lihat penjelasan rinci setiap JHE 


langkah identifikasi 
tulis multiplicity pada kamus data 5 


3. tentukan multiplicity JHE 


batasan kardinalitas 
terdiri dari: O 


batasan partisipasi ð 


atribut sederhana 


atribut campuran 


~ — (atribut bernilai tunggal 
-2: jenis: 
Langkah ke-2: Buat ERD bernilai jamak 
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atribut turunan 


4. tentukan atribut atribut kunci O 


temukan kata benda 


setiap JE & JHE: 
informasi apa yg dibutuhkan? 


domain 
langkah identifikasi n 
jenis 
setiap atribut: 
nilai awal 


boleh null 
tulis atribut pada kamus data ð 
gunakan tool UML 
5. gambar ERD 
cukup tulis atribut primary key jika kompleks 


6. periksa & 


masalah redudansi JHE 
sempurnakan ERD 2 


masalah perangkap 5 


